home *** CD-ROM | disk | FTP | other *** search
/ Acorn User: China / Acorn User China CD-ROM (UK) (Disc B) / Acorn User China CD-ROM (UK) (Disc B).bin / STUTTGART / PROBLEMS / DOC / BUGREPORT < prev    next >
Encoding:
Internet Message Format  |  1992-03-08  |  4.1 KB
  1. Path: newcastle.ac.uk!uknet!acorn!aglover
  2. >From: aglover@acorn.co.uk (Alan Glover)
  3. Newsgroups: comp.sys.acorn
  4. Subject: Re: Bugs (was Re: Annoying change between RO2 and RO3)
  5. Message-ID: <11312@acorn.co.uk>
  6. Date: 25 Nov 91 13:27:09 GMT
  7. References: <1991Nov25.091512.15438@cl.cam.ac.uk>
  8. Sender: aglover@acorn.co.uk
  9. Distribution: comp
  10. Organization: Acorn Computers Ltd, Cambridge, England
  11. Lines: 158
  12.  
  13.  
  14. Below is the standard electronic form used within Acorn, and by external
  15. testers, to report faults in software or hardware.
  16.  
  17. Instead of flaming about a bug simply fill in as much as you can on the form
  18. below, (remembering that the stranger the bug, the more info will be needed
  19. to make it happen controllably), and email it to me (aglover@acorn.co.uk).
  20. If a lot of supporting info is needed, it may be better to send a letter
  21. (possibly with accompanying disc) - address it to Customer Services, Acorn
  22. Computers Ltd., Fulbourn Road, Cherry Hinton, Cambridge, CB1 4JN, UK. 
  23.  
  24. I will not acknowledge receipt unless requested to, or respond to anything
  25. flame-like, so don't bother sending it - just send the information needed to
  26. reproduce a bug.
  27.  
  28. To give you an idea of what is and is not useful:
  29.  
  30. a) Do this, do this, do this and it does this (which it shouldn't).
  31.  
  32.    Very useful, especially when 100% repeatable.
  33.  
  34. b) Do this, do this, and it sometimes does this.
  35.  
  36.    Try to quantify how often 'sometimes' is. Failures are never truly random
  37.    - try to identify what missing factor is needed to make the bug
  38.    thoroughly reproducable.
  39.  
  40. c) This is cr*p, and doesn't do x, y, z.
  41.  
  42.    Unless we said it should do x,y and z this is categorised as a change to
  43.    the specification of a product, and is only likely to happen if a number
  44.    of people agree with you. No product can be everything to all people!
  45.  
  46.    Avoid saying something is cr*p. It's inaccurate, irrelevant, and just
  47.    gets people wound up.
  48.  
  49. d) X crashes all the time.
  50.  
  51.    Absolutely useless :-). Obviously it didn't do it for us during testing
  52.    or it would never have got released. Gradually eliminate elements of
  53.    your working environment until you find the source of the clash (which is
  54.    a typical reason for this). If you don't manage to localise if further,
  55.    turn your attention to any soft-loaded modules, and then to any Expansion
  56.    Cards.
  57.  
  58. Please note: The fact that bugs exist (or are alleged to exist) in a product
  59. is no guarantee that a new version will be released, or that the alleged bug
  60. will be fixed. 
  61.  
  62. Most of the fields are self explanatory, but here are some brief notes:
  63.  
  64. App. version number - from the Info Box, or from a module where appropriate.
  65.  
  66. Exact Hardware Config - be exact ! Include any expansion cards.
  67.  
  68. ROM Version Number - 2.00, 2.01 (A540 only) or 3.00 (A5000 only).
  69.  
  70. Tester Email name - in full please
  71.  
  72. Test Number - a number of your own devising
  73.  
  74. Fault Number - will be filled in by us - leave it blank
  75.  
  76. Priority - your idea of seriousness - rate as Low, Medium or High
  77.  
  78. Summary - keep it to one line of <60 characters
  79.  
  80. Status - will be filled in by us - leave it blank
  81.  
  82. Date encountered - guess! :-)
  83.  
  84. Test and Fault description - be verbose but relevant !       
  85.  
  86.  
  87. If you feel some feature is missing from an Acorn product then use the same
  88. form, but make clear:
  89.  
  90. a) Why the feature should be provided, and exactly what it should do.
  91.  
  92. b) Who it would be useful to (ie, what groups of people).
  93.  
  94. Again, remember that this is not provided as a way to let off steam,
  95. objectivity is important!
  96.  
  97.  
  98. Alan
  99.                                                 
  100.  
  101. --- cut here ---
  102.  
  103. FAULT REPORT
  104.  
  105. Application Name:               
  106.  
  107. Application Version Number:     
  108.  
  109. Exact Hardware configuration:   
  110.  
  111. ROM Version Number:             
  112.  
  113. Tester Email Name:              
  114.  
  115. Test Number:                    
  116.  
  117. Fault Number:                   
  118.  
  119. Priority:                       
  120.  
  121. Summary: 
  122.  
  123. Status:                         
  124.  
  125. Date Encountered:               
  126.  
  127. Test and Fault Description:     
  128.  
  129. --- cut here ---
  130.  
  131. --------------------------------------------------------------------------
  132. aglover@acorn.co.uk - Co-Moderator of comp.binaries.acorn/comp.sources.acorn
  133. Mail submissions to submit@acorn.co.uk, other mail to moderator@acorn.co.uk
  134.  
  135.